Application messages sent according to standardized application programming interfaces (API), such as Aeronautical Radio, Inc. (ARINC) 653 standards, are typically either a stream of bytes sent through queuing ports or a fixed set of parameters in a static arrangement sent through sampling ports. The application messages are sent between applications in different partitions through communications ports. A source application assembles multiple parameter values into a message structure and then outputs the message to a port. Then the platform software and hardware move the message, perhaps through an aircraft network, to one or more destination ports, from which destination applications read the message. Each destination application is programmed to extract data parameters it needs from specific positions within specific messages.
The system must adjust as the application developers change the applications. For example, when the producer of an application changes the location of a parameter in the message format, all applications that read that parameter must be changed. Also, if a parameter is moved to a different message, which is common when sensor signals are moved to a different I/O module, all the consuming software must change to consume the parameter from the different message.
Each change requires a rebuild of the application, and a re-test of both the application and the modules that include the application. Thus, as the software implemented by a system evolves, it is necessary to coordinate changes in message content and message format between all software development organizations as part of the software release planning Currently available systems commonly have 50,000-100,000 parameters that are sent in 2000-4000 application messages, so the task is extremely difficult and prone to errors, often leading to project delays and expensive rework.